Buch of quickies:

• First, I'm moving from livejournal to blogger. Mainly because blogger allows me to email pictures/videos from my cellphone and automatically converts them to blog entries. To avoid spamming planet with unnecessary entries, only postings tagged with "Debian" be syndicated to p.d.o.
  
• Was invited to UDS and Prague. Quite different from conferences where I've been before (debconf, FOSDEM). Less time spent with one person presenting and rest of room listen, more time people discussing the topic of session. Atleast this was the case in the Mobile track I mostly followed.
  
• Testing scripts now consider Armel a Release architecture. \o/. The armel debian-installer should also be part of debian-installer beta2 really soon(tm) . Only getting testing-security running properly is tricky at the moment...
• fuck I'm old now.
  

Last weekend I was at FOSSCamp. Since I live in Prague I wanted to go to Ubuntu Developer Summit (UDS) each day, but unfortunately I had some exams, so I only went on Wednesday and Friday.

On Wednesday I first met Lars Wirzenius:


we agreed to go to pub in the evening. Then I did a little work, there was quite a nice view from the window (Prague castle on the horizon):



and I went to the #ubuntu-devel-summit IRC channel and pinged Scott Kitterman, whom I new from the Debian Python Modules Team (DPMT), but didn't know how he looks like. We met and once I knew Scott, it was easy to get around, so he introduced me to Steve Langasek (pronounced Lang ek). We agreed to go to pub as well. Steve lives in Portland, OR, where I spent the summer 2005 and Scott is from Baltimore where I spent the summer 2006.
Then I also met Riku Voipio, Martin B hm, Christian Reis (whom I asked if it's possible to support Debian unstable on Ubuntu Personal Package Archives and he said that it will probably happen, so that's really cool -- I also offered my help with this) and others, so in the end, there were 14 of us going to the pub, so I chose again the same pub as with the FOSSCamp people and it seems it tasted good again:




Notice the sv kov na smetan above, my favourite meal. Good choice Scott. :)





Ok, that was on Wednesday. On Friday I arrived at around 3pm, looked at the schedule table and noticed that Matthias Klose should be at UDS too, so I started IRC and pinged him. Fortunately, Emilio Pozuelo Monfort, whom I know from DPMT as well, replied first so we met, it was cool and he showed where Matthias is. I am very glad I met him, so we discussed python-central and python-support packages and why we have them both, also with Scott later on.

When I was waiting for Matthias, I sat next to Nicolas Valc rcel, started my laptop and begun looking at some SymPy bugs and Nicolas noticed that and said -- "You are developing SymPy?", I said "Yes.", flattered. And he showed me a bug with plotting and Compiz, so we immediately reported that to pyglet.

In the evening people continued to some kind of a party, but unfortunately, I was already going to some other pub.

Overall, even though I was there for only two afternoons, it was just awesome and I utterly enjoyed meeting all the people I knew from mailinglists and IRC.

Approximately one year ago danske bank swallowed the second-largest Finnish bank, Sampopankki. Last weekend, the perfectly fine working web-bank was flushed down the toilet and replaced with Danske Banks infrastructure. So far the results are quite horrific:

• People are reporting missing/too much money been shown in their accounts.
  
• Standard ssl/html based frontend has been replaced by a java applet. Worse, it needs a JNI library. Apparently to sniff your PC configuration. Surprisingly they provide a (ia32) Linux JNI lib as well. Compile once, run to the hills...
  
• The new webbank has security holes. url's that show a competing banks login prompt instead of sampo/danske bank are circulating on IRC. Apparently the danish website has the same bug too. The bank representative has (so far) refused to acknowledge there is a security hole.
  

A surprising number people have dismissed the whole issue as "IT business as usual, why complain?". Sure, we all *know* that most IT projects deliver late, fail to work until the first service pack, fail to import data properly from previous versions or simply fail completely. But is that something we should just accept as part of life? Even for banks that are (were) holding our money?

Riku Voipio just sent a "bits from armel porters" in debian-devel-announce (sorry, no link: I'm offline while writing this). I just want to point out that the success of armel becoming an official architecture is also due to the very clever and efficient way the porters interacted with maintainers. As a very small example, Riku recently sent a bug report about samba for armel-related issues and this bug report was full of useful and precise information. Even without Steve Langasek endorsing the fixes, I would have applied the suggested changes even though I don't understand a single bit of it: just because it was so obvious that Riku knew what he was talking about. As Riku points in his announce mail: this is a great succes and this also demonstrate that good interaction between package maintainers in Debian can still happen, despite some general perception that maintainers are "grumpy".

Texas Instruments (TI) joins Linux foundation. Congrats.

TI will help foster the growth of the Linux platform and collaborate with industry leaders who define both technical and operational best practices around open source software. .... TI will further ensure that its customers have the necessary tools to create innovative and differentiated Linux-based mobile devices that use the OMAP platform and DaVinci technology.

How about starting with

• Releasing the OMAPx TRM (Technical Reference Manuals) available to Linux community
  
• Documenting your DSPs and providing a OSS bios for them (compilable with a OSS toolchain)
  
• Release drivers for _all_ parts of OMAP chips, such as the AES accelerator, Jazelle java acceleration, powerVR 3d and so on.
  

If you continue providing documentation only for "high volume customers", your membership in Linux Foundation is a PR stunt at best.

accepted: dpkg_1.14.16.6_armel.changes

AKA: ftp-master is now accepting armel packages

Thanks AJ!

current todo item: populating the archive cleanly

Sune asked where debian/armel is. Inspired by the blog, I posted a status update to debian-arm mailing list.

Other random updates

1) apt-get install recommends has now been enabled by default. This bites sbuild and pbuilder (#448562). In your buildd chroots set APT::Install-Recommends "false"; and be aware that you pbuilder build results might not be as pristine as we all have got used to..

2) I blame the rapidly growing kittens here for distracting me...

Sneak preview of Debian/maemo packages running on Debian/Armel port device.

Thanks to Riku Voipio's advice, my slug now runs an EABI kernel with OABI compat support. As a bonus I have the latest 2.6.18-5 abi kernel :-) .

Things to remember when trying to do the same with your slug:

• running make menuconfig (somehow) with the debian/arch/arm/config-ixp4xx file as config will, most definitely disable the compilation of the internal driver
• before flashing a new linux image, check that the drivers for the network interfaces you expect to be up after reboot are present in the deb
• arm iptables will fail with an eabi kernel, even if it has oabi compat support, you will need to install iptables in the armel chroot; so if you use iptables at all, you need to pass that invocation to the iptables binary from the armel chroot
  

I just chroot-ed into an armel chroot and rrdtool made some nice and meaningful graphs.

Instead of:


I got:



Some complaints:

• migrating to armel will probably be a pain, if care is not taken to migrate settings, scripts and everything in /etc
• the load spikes up just to make these graphs :-(
  

Update: it didn't work .... :((

eddy@ritter ~ $ grep '##### kern' -A 2000 /var/log/syslog grep -E '(reset ####)'
Aug 6 11:19:00 ritter manual message: ##### kernel was changed to linux-image-2.6.18-4-ixp4xx_2.6.18.dfsg.1-12etch2.1_arm.deb #####
Aug 6 11:23:08 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 6 11:35:15 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 6 11:52:41 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 6 11:54:47 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2

---

I cross built this:

Changes:
linux-2.6 (2.6.18.dfsg.1-12etch2.1) stable; urgency=low
.
* Non-maintainer upload.
* ixp4xx kernel:
Disabled options:
- USB_EHCI_SPLIT_ISO
- USB_EHCI_ROOT_HUB_IT
Enabled options:
- USB_BANDWITH

And it took me on my amd64:

real 105m0.331s
user 79m43.423s
sys 12m46.324s

Is not an upload, is just my try to fix this issue. Let's see if it works.

Oh, thanks to Riku for pointing out that cross building the kernel is trivial.

The debian armel port reached one milestone yesterday: Being able to run debootstrap from DD-signed, upto-date unmodified debian/unstable packages.

Looking backward:

* When watching the buildd's, the worst of Debian is visible. You don't spend much time wondering on successful builds. The time goes into wondering about the crappy code that fails to compile, the maintainers who ignore RC bugs for months, code with dead upstream..
* bootstrapping a Debian port is still painful. Fortunately Lennert did that for us this time.
* Most maintainers are very responsive, and are happy enough apply patches that help even unofficial ports. The few who ignore patches or are else effectively MIA can cause long delays...
* C++ code is evil. or at least the g++ implementation of it. A random game written in C++ can take 5h to build, when even the most complex C apps compile in 2-3 hours (with a few exceptions like glibc and linux-2.6). Worse, g++-4.2 seems to be another 10-20% slower than g++-4.1... Remember God kills a kitten every time you upload a c++ package unnecessarily!.
* Esoteric language bindings suck too.

Looking forward:

There is some 500 (out of 7100) packages that in Dep-Wait state due some missing packages on armel port:
* ~290 packages that would need FORTRAN (!). specifically the old g77 version...
* ~80 packages waiting for objective C / gnustep
* ~70 packages waiting for ghc6 or related Haskell code
* ~40 packages waiting for Java (being worked on)
* ~15 packages waiting for mono (patch in BTS)
* Then there usual crop of esoteric languages, packages failing to build with current unstable on any port, and packages build-depending on stuff removed or to-be-removed packages.

Effectively this means getting armel over 90% built of Debian needs either g77 to armel or getting Debian to migrate from g77 to gfortran (which is available but not throughly tested on armel). I'm working on the second route..

* Start building d-i images. So that Eddyp can have blazingly fast softfloat rrdtool on his nslu-2 without bugs and trouble.

* Request inclusion into Debian ftp archives. I think with the latest milestones, armel should be ready for archive as a "second class citizen". Inclusion for lenny needs still some work.

* Finally: there's tablets and phones waiting to for Debian armel mobile ;)

UK military spokesman Major Mike Shearer said: "We can categorically state that we have not released man-eating badgers into the area."

Source: BBC

Since the release team update got the arm architecture names mixed, chances are that others are confused as well.

* arm - This is the current in-Debian, little-endian hard-float old-abi port.

This is somewhat inefficent port, as the hard-float code needs to be emulated
in the kernel. It is also depreciated by upstream.

* armeb - This was a effort to create an big-endian old-abi port.

Since the Linksys NSLU-2 got it's Ethernet driver reverse engineered and thus it became possible to run little-endian Debian on it, interest on this port has been weak. If interest in bigendian arm returns, it will probably be re-ported using EABI and softfloat.

* armel - This the shining new little-endian EABI (and thus soft-float) based architecture.

THIS IS SPARTA^W THE FUTURE.

All doom and gloom? far away from that.

The good:

* Arm port is now third most popular port according to popcon.
* This mostly thanks to the popularity of Linksys NSLU-2, a tiny 80 computer able to run Debian. Do you have a old pentium sucking up electricity in your closet? Do a service to earth and replace it with a NSLU-2!
* Armel (Arm EABI) is now at "63.41% up-to-date. That's 4515 packages built out of 7121". See the fancy Graph for the progress. Catching up sid has been achieved with just two buildd's (Thecus N2100) in my apartment and Aurelien Jarno building selected packages. Plus of course pioneering work from Lennert Buytenhek and people who created EABI in upstream.
* All core packages except apt (which hasn't seen a upload to sid since etch) have now armel support in official Debian packages.
* the old arm port has started catching up in up-to-dateness again, now that all buildd's have a recent enough kernel for glibc 2.5 (2.6.12+)

The bad:

* We need someone to take responsibility on the toolchain for arm. Java is semi broken on arm, Fortran, Java and objc need work for armel.
* There is still communications problems. It took quite a while to find out why glibc 2.5 doesn't work on some buildd's.
* People have lost interest in Bigendian arm port after nslu-2 started working with the regular Little-Endian arm port. General consensus is that bigendian port would only matter for highend networking gear.

The future:

* More supported devices. Now we support NSLU-2, Thecus N2100 and a few related IOP based devices plus netwinders. Arm boasts their partners shipped 2450 Million units based Arm technology in 2006. Would you like to run Debian on your brand new scsi RAID card? mp3 player? Cellphone? Internet Tablet? Washing machine? Your choice!
* Better recovery options. Many arm devices are headless, and if it crashes or doesn't boot, figuring out what went wrong is tricky. This is not really arm specific, but comes up often enough in debian-arm list.
* Anti-bloat festival. Many arm devices have very little storage and RAM available. To run debian on these, we need to figure out who to get rid of extra FAT. Less bloated software is everyones advantage.

I tried to ask our cats if they felt threatened by CDBS. They didn't seem really worried.

I'm not sure if it is entirely fair to blame CDBS for complex packaging issues. If CDBS was not available, more maintainers would just cook up their own spaghetti packaging scripts. The balance needs to be somewhere between "everyone reinventing the wheel" and "frameworks that are harder to use than the raw stuff". Currently I would recommend only using CDBS for simple packages.

I was born on 19771102T2018+0200. Thus, it is now almost an hour into my 29th, that is, 035th, that is, 0×1Dth birthday. And what am I doing right now? Celebrating? No, actually I am writing a novel. This is the fourth time I participate in the interNational Novel Writing Month. The MissionImpossible is to write 50 000 words of fiction, a single story, in thirty days. That makes about 1667 words a day, roughly half a dozen pages of manuscript for each 24 hours of this month. I won last year, but whether I cheated or not only $DEITY can tell. I certainly can’t. This year, I want to finish with flying colors. Yesterday (the first day of the hellride) I learned a valuable lesson. If my writing slows to a crawl, then I am writing something I should not be writing. Rethinking the scene in question, to include some sort of jeopardy, usually helps. Not that my writing is anything close to stellar when it flows; but in NaNoWriMo it doesn’t matter. Quantity is the only thing that matters, quality is left as an exercise to the reader. Um. No. Quality is the worry of the National Novel Editing Month, in March. Last year I cat-vacuumed by writing blog posts about the Finnish judicial system. This time I wised up and made it a topic of my novel. It is a sf story, set in a future colony world populated by Finns. Who have refrigerated the Finnish system. Well, almost. They have changed it enough that I can call it fiction. Um. Also to be able to write about things that cannot be written. If it is fiction (in fact, not just in fiction), I am not breaking my oath to keep the deliberations secret. Because it’s fiction, I am not actually writing any court case I have sat in. Setting it in a different world allows me to create court cases that would not exist in the real world. Like trying someone for a murder they are alleged to have committed fifty years ago on another planet, with no physical evidence. Oh wait, almost sounds like the Lake Bodom murders. Damn. Oh right, I forgot. I didn’t sit in that panel of judges. Here is a bit of infodump I wrote two hours ago:

Some of the first-generation boardmen had told him stories about grand courthouses with metal detectors at the doors, a dozen courtrooms, the same number of judges and hundreds of boardmen. That was in Finland on Old Earth, of course. Not so here. The courthouse was really a modified small apartment building. There were no metal detectors; the technology was hellishly expensive and wasteful. There were no guns on the planet (except in the Old Earth Museum) and knives were not a problem. There were only eight thousand people, so one judge was quite enough, and twenty boardmen. Well, four judges, one at the Thing’s Court and three at the Apellate court. And occasionally a new graduate from the university doing their clerking to obtain their attorney status. The courthouse had two large courtrooms. The larger generally hosted criminal trials of the Thing’s Court; the smaller was used by the Apellate court when they wanted to hear evidence themselves. Which was not very often. Civil cases sometimes used both rooms at the same time; the wall separating them could be easily removed and put back. The old-timers did approve of the layout and furnishing of the big room. Apparently they did much resemble the Old Earth system. Riku went in, said hello to the janitor and used the ultra secret boardman access hatch to reach the back room. He was the first boardman there, so he took his time to check his appearance, took a crap and made coffee. Justice must not only be just, it must also look just and stay sharp.

Wish me luck in this insane journey, would you? (Notice how I cleverly avoided asking for conga rats for the birthday. Tee hee. Or something.)

On Friday, a branch for GCC 4.2 finally got created, which means that we will hopefully see a release in a few months. The branch should have been created ages ago but the number of regressions just wouldn't go under 100 until recently. During that time, basically since I completed my tests with GCC 4.1, I've been busy testing snapshots of 4.2. I've mainly been testing on em64t (amd64), powerpc and ia64, but I also did some runs on alpha, mips, mipsel, s390 and sparc. Recently, I started testing it on ARM. Being an embedded architecture, ARM isn't terribly fast compared to some other architectures. However, Intel's IOP line is quite interesting and is used in a number of NAS devices. They typically include SATA and often have expandable memory. The device some ARM people are currently working with is the Thecus N2100. A port of debian-installer is underway but more on that later. Since my N2100 is not permanently connected to the Internet, Riku Voipio kindly gave me access to his to do some GCC tests. I started several weeks ago using gcc-snapshot 20060922-1 and it has been compiling happily since. I sort packages by their age, starting with old packages, so while there has been quite a bit of progress since I started, lately it has been going quite slowly. With about 2000 packages compiled in 3.5 weeks, I reckon that GCC 4.2 will be released before I've compiled the full archive. I've therefore been thinking of using distcc to speed the process up. The idea is to run the build process natively on the ARM box but use distcc to perform the actual compilation on another box, namely on a fast machine that has an ARM cross compiler. Unfortunately, I don't have access to such a setup right now. However, I strongly believe that this is a good alternative to test GCC on slower systems and in fact Bill Allombert is currently testing whether it could be used for the m68k port. Finally, Intel's new IOP 34x CPUs are also interesting for this kind of work given that they feature a cache and go up to 1.2 GHz with two cores. P.S. If someone is interested in fixing bugs, I have tagged package bugs related to GCC 4.2.

After a bunch of trains, subways, planes, buses and taxis I’ve finally arrived at Oaxtepec (Mexico) to attend DebConf6, the annual Debian conference. Besides doing some Debian work, having some fun with long-time-no-seen friends and enjoying the swimming pool, there are several interesting talks I’m interested on:

• SELinux UML instances, by Manoj Srivastava
• The X Community - History and direction, by Keith Packard, who has been involved in X development since the 80s
• Experiences with large Custom Debian Distributions installations, by Knut Yrvin (Skolelinux)
• Scratchbox 2, cross-compiling in Debian, by Riku Voipio
• Debian and the $100 laptop, by Jim Gettys
• debian-installer internals
• several interesting BoFs about optimizing boot time, libapt-front, embedded Debian, …

Time for lunch here!

Relatively simple task - given a pid, find out if it is in the same chroot as you. Until now we simply used the following code, which would error out if the given pid was not in chroot like us:

readlink /proc/$pid/root

All good things end up eventually, this time with the soon to come out 2.6.18 Linux kernel release. A recent commit changes the permissions of symlinks in /proc, (not only /proc/$pid/fd like it would seem from the commit message). Using ptrace as security policy is not a bad idea. If you can access the information via ptrace, hiding it from /proc made little sense. Which leads to the scary observation that one can ptrace any process with same UID outside your chroot sandbox. This is not a security bug, since one can escape chroot anyway. I just hadn't realized *HOW* easy it was.

Back to the topic, using /proc/$pid/root was not a standard or even documented interface, so I can hardly complain. I'm still left without a proper replacement:

So what AM I supposed to use?

At least for my personal schedule, this is day 0 of Debconf. After being driven to Paris Orly airport by Elizabeth (my wife, dudes), I easily met with M. Adn ne Trojette and Nicolas Fran ois. A very quiet flight with about 30 people in a 200-seat plane lead us to Madrid Barajas (the flight was less quiet for Adn ne who has to suffer my constant babbling...."talks too much" as says my friend Konstantinos). This Barajas airport deserves a special mention, indeed. Its terminal 4 is incredibly H.U.G.E. More precisely it appears as huge because the two terminals are long straight buildings about 1.5 km long. As minutes were passing we easily met with Riku Voipio, Petr Rockai and Rapha l Hertzog. A few beers (for Riku, Nicolas and I) helped spending the couple hours of waiting time friendly and the French Mini-Cabal was even able to speak English (well, Frenglish...anyway). Nicolas and I then have been the local attraction but doing some hacking seated on the floor in the toilets (for caballeros, though) which is the only place with power sockets. Then we boarded in a huge A340 completely filled with people who, what a surprise, all speak Spanish. We finally met with Guido G nther whose flight had been delayed. So, finally, we will be 7 of us landng in that flight. That will make a really packed SUV cab. We're now seated, flying over Portugal and Galicia, the 4 of us French geeks hacking on our laptops (seems to me that other passengers are a bit staring at us...). Time to sleep and....see you in MEX for bubulle's blog of Debconf - day 1.